Конфигурация¶

Настройка потоков выполнения¶

Tarantool создает свои собственные потоки выполнения (tx, wal, relay и прочие). Помимо этого, каждый экземпляр Scheduler создает столько потоков tokio-runtime-w, сколько vCPU доступно на сервере.

С помощью переменной окружения TOKIO_WORKER_THREADS в инвентаре необходимо указать, сколько потоков tokio-runtime-w должно быть создано каждым экземпляром Scheduler по умолчанию.

Рекомендованное значение TOKIO_WORKER_THREADS – на 2 меньшее, чем количество ядер. Это нужно, чтобы 2 ядра оставались доступными для потоков Tarantool tx и wal+relay. Если доступных ядер для эти потоков не останется, работа СУБД будет заблокирована.

Пример:

    tcs_scheduler_1:
      hosts:
        tcs-scheduler-01:
          http_listen: '192.168.1.10:8777'
          with_metrics: true
      vars:
        extra_env:
          TOKIO_WORKER_THREADS: 1
        tcs_storage_group_name: tcs_storages
        tcs_storage_replicaset_name: tcs_storages_r01
        ansible_host: '192.168.1.10'
        ansible_port: 22
        ansible_user: '{{ super_user }}'

Настройка сред выполнения¶

Настройка отдельных сред выполнения (runtimes) может понадобиться, например, для обработки ресурсоемких запросов.

Можно задать следующие среды выполнения:

• acceptor - среда выполнения для приема запросов. Через нее проходят все запросы, но она требует мало ресурсов.

• requests:default - среда выполнения для обработки запросов, используемая по умолчанию.

• requests:additional:* - дополнительные среды выполнения для обработки ресурсоемких запросов. Для них рекомендуется настраивать малое количество потоков и низкий приоритет.

• streaming - среда выполнения для обработки потоковых SQL-запросов.

• internal - среда выполнения для внутренних нужд.

Настройки, которые можно задать для каждой среды выполнения:

• name - имя среды выполнения.

• thread_count - количество потоков для среды выполнения. При задании этого значения нужно оставлять часть потоков для нужд системы и других приложений.

  Важно

  Если значение thread_count не задано, то оно берется равным количеству ВСЕХ ядер, не только свободных. Это может привести к сбою работы TCS.

• priority - приоритет среды выполнения, от 0 (самый низкий) до 99 (самый высокий).

  Финальное значение приоритета выставляется TCS в зависимости от операционной системы. Чем больше указанное в конфигурации значение priority, тем больше будет выделяться времени на работу задач в этой среде.

  Если приоритет не задан, то TCS выставит его автоматически.

Пример:

aggregator:
  runtimes: # секция для настройки сред выполнения
    acceptor:
      name: acceptor
      thread_count: 30
    requests:
      default:
        name: requests-default
        thread_count: 62
      additional:
        name: analytics
        thread_count: 5
        priority: 0
    streaming:
        name: streaming
        thread_count: 5
    internal:
        name: internal
        thread_count: 10

Данный пример приводится для сервера со 128 ядрами. Для сервера с другим количеством ядер нужно подбирать другие числа.

Также обратите внимание, что в примере оставлен запас в 16 ядер для других потоков Tarantool и прочих нужд сервера.

Настройка мониторинга¶

listen: 0.0.0.0:7778
with_metrics: false
features:
  - experimental_api
nodes:
  - admin_iproto_endpoint: localhost:3301
    admin_http_endpoint: localhost:8081
    api_http_endpoint: localhost:7777
  - admin_iproto_endpoint: localhost:3302
    admin_http_endpoint: localhost:8082
    api_http_endpoint: localhost:7776

groups:
  aggregators:
    roles:
      - roles.metrics-export
      - app/aggregator_role
      # - app/etcd_stateboard_client
      - app/stateboard_role

Настройка размера буферов записи¶

Для обработки больших запросов на обновление данных может понадобиться увеличить размер буфера записи. Для этого нужно задать нужное количество блоков буфера в параметре buf_block_count (по умолчанию 16). При этом нужно учитывать, что размер одного блока в буфере равен 8192 значениям (параметр block_size).

Размер буфера первоначально задается перед первым стартом TCS, на пустой базе данных. Дальше значение параметра buf_block_count можно только увеличивать. Это можно делать следующими способами (оба способа – без остановки TCS):

• С помощью параметра buf_block_count (для всех таблиц). Для этого следует задать новое значение параметра в конфигурации TCS на мастер-экземпляре Storage (а при настроенном шардировании – на мастер-экземпляре Storage каждого набора реплик) и перегрузить конфигурацию в etcd.

  Пример: увеличение размера строчного буфера со 131072 значений (8192 * 16, размер по умолчанию) до 1048576 значений (8192 * 128):

  groups:
    aggregators:
      roles_cfg:
        app/aggregator_role:
          tcs:
            block_size: 8192
            buf_block_count: 128
  

  В результате размер строчного буфера увеличится для всех таблиц.

• С помощью скрипта миграции app.storage.schema.lua, (индивидуально для нужной таблицы). Для этого следует вызвать метод grow_table_record_buffer_block_number() с указанием следующих аргументов:

  • catalog – название каталога;

  • schema – название схемы;

  • table_name – название таблицы;

  • new_blocks_number – новое количество блоков в строчном буфере для данной таблицы.

  Пример: увеличение размера строчного буфера до 1048576 значений (8192 * 128) для таблицы db.public.employees:

  require('app.storage.schema').grow_table_record_buffer_block_number('db', 'public', 'employees', 128)
  

  Скрипт требуется запустить на мастер-экземпляре Storage (а при настроенном шардировании – на мастер-экземпляре Storage каждого набора реплик).

Настройка частоты обновлений представления для чтения¶

Представление для чтения обновляется раз в столько миллисекунд, сколько указано в параметре .aggregator.rv_update_ms. По умолчанию, 100. При необходимости можно задать другое значение. Пример:

aggregator:
  rv_update_ms: 100000

Настройка обработки потоковых запросов¶

Для корректной работы TCS с потоковыми SQL-запросами на HTTP-адресе /streaming/sql требуется выполнить следующие настройки в инвентаре:

• В конфигурации экземпляров добавить ключ http_listen_streaming (адрес сервера для обработки поточных запросов) на том же уровне, где добавлен ключ http_listen. По умолчанию адрес сервера для обработки поточных запросов равен 0.0.0.0:7877.

  Это необходимо сделать, чтобы предотвратить конфликт серверных адресов.

• В конфигурации сред выполнения (runtimes) добавить ключ streaming и указать количество потоков для этой среды выполнения (thread_count). По умолчанию количество потоков равно количеству процессорных ядер.

  Это необходимо сделать, чтобы в процессе tarantool не создавалось слишком большое количество потоков.

Пример:

aggregator:
  http_listen: '0.0.0.0:7777'
  http_listen_streaming: '0.0.0.0:7877'
  runtimes:
    streaming:
      name: streaming
      thread_count: 2

Настройка максимального времени выполнения запросов¶

В TCS заданы ограничения по умолчанию на максимальное время выполнения запросов:

• для всех типов запросов, кроме аналитических расчетов: 5 мс

• для каждого счетчика в аналитических расчетах: 4,5 мс

По истечении этого времени TCS прерывает обработку запроса и присылает ответ HTTP 408 Request timeout.

При необходимости эти значения можно изменить в консоли с помощью Lua-инструкций на всех серверах с Tarantool:

require('app.roles.tcs.storage.api').configure_http_timeout_ms({timeout_ms})

require('app.roles.tcs.storage.api').configure_computation_max_duration_ms({duration_ms})

Перезагрузка при этом не требуется.

Настройка автоудаления данных по времени¶

В TCS есть возможность автоматически удалять данные из основного хранилища и из буфера записи таблицы по мере их устаревания.

Для настройки автоудаления следует задать следующие параметры:

1. В конфигурации данных:

   Добавить поле с параметром "data_type": "ts" (тип данных timestamp) во все таблицы, для которых нужно настроить автоудаление данных. Название поля может быть любым. Индексирование задавать не обязательно.

   Пример: поле с названием timestamp.

   name: timestamp
     data_type: ts
   

2. В конфигурации TCS:

   a. В разделе tables добавить именной подраздел для каждой таблицы, для которой нужно настроить автоудаление данных. Имя подраздела должно иметь вид "каталог.схема.таблица", где все имена разделены точками, например "company.public.attributes".

   В каждом именном подразделе нужно указать два параметра:

   • ttl – время жизни данных (в миллисекундах). Минимальное допустимое значение равно 10000.

   • timestamp – название поля с типом данных ts в соответствующей подразделу таблице, по которому будет производиться автоудаление.

   Пример: настройка автоудаления данных старше 10 секунд для таблицы company.public.attributes.

   tables:
     company.public.attributes:
       ttl: 10000
       timestamp: timestamp
   

   b. В разделе ttl_eviction указать интервал schedule (в миллисекундах) для срабатывания автоудаления. Минимальное допустимое значение равно 10000.

   Чтобы действие автоудаления для всех таблиц было предсказуемым, значение интервала schedule рекомендуется задавать кратным всем значениям ttl, указанным для таблиц с данными. См. подробности в примере полной конфигурации для автоудаления ниже по тексту.

   Пример: удаление устаревших данных раз в 20 секунд.

   ttl_eviction:
     schedule: 20000
   

   c. В разделе ttl_eviction также можно указать параметр include_record_buffer (по умолчанию true) для того, чтобы исключить автоудаление данных из буфера записи.

   Пример: исключение данных буфера записи из автоудаления.

   ttl_eviction:
     include_record_buffer: false
     schedule: 20000
   

Пример

Полная конфигурация TCS с настроенным автоудалением данных:

groups:
  aggregators:
    roles_cfg:
      app/aggregator_role:
        tcs:
          buf_block_count: 4
          default_column_values_limit: 200000
          schema:
            company1:
              public:
                attributes:
                  columns:
                    - name: i32_0
                      data_type": i32
                    - name: timestamp
                      data_type: ts
            company2:
              public:
                attributes:
                  columns:
                    - name: i32_0
                      data_type: i32
                    - name: timestamp
                      data_type: ts
            company3:
              public:
                attributes:
                  columns:
                    - name: i32_0
                      data_type: i32
                    - name: timestamp
                      data_type: ts
            tables:
              company2.public.attributes:
                ttl: 10000
                timestamp: timestamp
              company3.public.attributes:
                ttl: 20000
                timestamp: timestamp
              ttl_eviction:
                include_record_buffer: false
                schedule: 10000

В данном примере автоудаление данных настроено только для двух таблиц из трех. Для таблицы company1.public.attributes не задан именной подраздел в разделе tables, таким образом автоудаление для этой таблицы не настроено.

Обратите внимание, что интервал schedule (10 сек) кратен значениям ttl, указанным для двух остальных таблиц (10 и 20 сек). Это корректная конфигурация с предсказуемым эффектом: на каждое срабатывание автоудаления будут удаляться данные старше 10 секунд в таблице company2.public.attributes, а на каждое второе срабатывание – данные старше 20 секунд в таблице company3.public.attributes.

Однако, если бы интервал schedule не был кратен какому-либо из значений ttl (например, если бы schedule равнялся 15 сек), то в таблицах скапливались бы устаревшие данные. Так, 5 секунд (сверх установленных 10) ждали бы удаления устаревшие данные в таблице company2.public.attributes, и 10 лишних секунд (сверх установленных 20) ждали бы устаревшие данные в таблице company3.public.attributes.

Если автоудаление из буфера записи срабатывает в момент переноса данных из блока буфера записи в основное хранилище, то автоудаление для этого и последующих блоков данного буфера будет отложено до наступления следующего интервала schedule.

Настройка обработки запросов на обновление данных¶

По умолчанию запросы на HTTP-адрес /update производят обновление данных сразу в двух местах: в буфере записи и в колоночном хранилище.

При необходимости можно отключить обновление колоночного хранилища для всех запросов на обновление. Для этого нужно:

1. Указать в конфигурации TCS параметр roles_cfg.tcs.aggregator.disable_column_update: true (по умолчанию false).

2. Поменять конфигурацию в etcd (с помощью TCM или вручную).

3. Перезапустить все экземпляры Storage.

В результате по итогам выполнения запросов будет обновляться только буфер записи.

Настройка параллельного чтения колонок¶

Для параллельного чтения колонок можно задать количество потоков обработки запроса (партиций) в параметре .aggregator.partition_count. По умолчанию, 1. При необходимости можно увеличить это значение, чтобы ускорить обработку запросов. Пример:

aggregator:
  partition_count: 10

Рекомендуется оставлять значение по умолчанию, либо задавать значение в два раза меньше количества ядер CPU.

Настройка прямой/обратной записи данных¶

В TCS запись данных в таблицы по умолчанию производится в прямом порядке (запись начинается со свежих данных).

При необходимости порядок записи для всех таблиц можно изменить на обратный (запись будет начинаться со старых данных). Для этого нужно указать параметр reverse_order: true в разделе tcs:

app/aggregator_role:
  tcs:
    block_size: 8192
    default_column_values_limit: 200000
    buf_block_count: 4
    reverse_order: true

По умолчанию предполагается reverse_order: false (прямой порядок записи).

Настройка типа хранилища таблицы для вставки данных¶

При вставке данных в таблицы при помощи запросов на HTTP-адреса /sql и /v2/insert, данные попадают или в буфер записи, или в колоночное хранилище.

Глобальная настройка insert_into_columns позволяет определить, куда по умолчанию будет производиться вставка: в буфер записи или в колоночное хранилище таблицы:

• insert_into_columns: true - при запросе на HTTP-адреса /sql и /v2/insert вставка данных будет производиться в колоночное хранилище таблицы.

• insert_into_columns: false - при запросе на HTTP-адреса /sql и /v2/insert вставка данных будет производиться в буфер записи таблицы.

По умолчанию у настройки insert_into_columns выставлено значение false:

tcs.aggregator.insert_into_columns: false

Проверка конфигурации данных¶

При загрузке конфигурации проверяется, удовлетворяет ли конфигурация данных следующим условиям:

• структура конфигурационного файла соответствует модели данных TCS (при этом разрешены любые другие поля, не оговоренные в описании модели);

• для всех полей указаны обязательные поля name и data_type;

• в поле data_type указан один из поддерживаемых типов данных;

• глубина индекса (index_depth) везде строго положительна или равна null (значение 0 в конфигурации недопустимо).